This is a screenshot of RootkitRevealer detecting the presence of the popular HackerDefender rootkit. The Registry key discrepancies show that the Registry keys storing HackerDefender's device driver and service settings are not visible to the Windows API, but are present in the raw scan of the Registry hive data. Similarly, the HackerDefender-associated files are not visible to Windows API directory scans, but are present in the scan of the raw file system data.
You should examine all discrepancies and determine the likelihood that they indicate the presence of a rootkit. Unfortunately, there is no definitive way to determine, based on the output, if a rootkit is present, but you should examine all reported discrepancies to ensure that they are explainable. If you determine that you have a rootkit installed, search the web for removal instructions. If you are unsure as to how to remove a rootkit you should reformat the system's hard disk and reinstall Windows.
In addition to the information below on possible RootkitRevealer discrepancies, the RootkitRevealer Forum at Sysinternals discusses detected rootkits and specific false-positives.
RootkitRevealer should never report this discrepancy since it uses mechanisms that allow it to access any file, directory, or registry key on a system.
A file system scan consists of three components: the Windows API, the NTFS Master File Table (MFT), and the NTFS on-disk directory index structures. These discrepancies indicate that a file appears in only one or two of the scans. A common reason is that a file is either created or deleted during the scans. This is an example of RootkitRevealer's discrepancy report for a file created during the scanning:
C:\newfile.txt
3/1/2005 5:26 PM
8 bytes
Visible in Windows API, but not in MFT or directory index.
Rootkits can attempt to hide themselves by misrepresenting the size of a Registry value so that its contents aren't visible to the Windows API. You should examine any such discrepancy, though it may also appear as a result of Registry values that change during a scan.
Registry values have a type, such as DWORD and REG_SZ, and this discrepancy notes that the type of a value as reported through the Windows API differs from that of the raw hive data. A rootkit can mask its data by storing it as a REG_BINARY value, for example, and making the Windows API believe it to be a REG_SZ value; if it stores a 0 at the start of the data the Windows API will not be able to access subsequent data.
The Windows API treats key names as null-terminated strings whereas the kernel treats them as counted strings. Thus, it is possible to create Registry keys that are visible to the operating system, yet only partially visible to Registry tools like Regedit. The Reghide sample code at Sysinternals demonstrates this technique, which is used by both malware and rootkits to hide Registry data. You can use the Sysinternals RegDelNull tool to delete keys that contain embedded null characters.
This discrepancy will occur if a Registry value is updated while the Registry scan is in progress. Values that change frequently include timestamps such as the Microsoft SQL Server uptime value, shown below, and virus scanner "last scan" values. You should investigate any reported value to ensure that its a valid application or system Registry value.
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\RECOVERYMANAGER\MSSQLServer\uptime_time_utc
3/1/2005 4:33 PM
8 bytes
Data mismatch between Windows API and raw hive data.